Lifecycle Psychology

If you want to improve your computer system implementation track record, you need to take my short course on lifecycle psychology. Yes, I did say psychology: when push comes to shove, it is the people who install, troubleshoot, support, and learn how to use your new system that will determine whether the system succeeds or fails. If you are willing to learn one simple concept, you can use some basic psychology to build winning implementation teams.

Before we start, there is a prerequisite course on system lifecycle. Normally, this topic requires half a semester of class work, but to save time we'll use the very abridged version:

• Lifecycle Stage 1: Get the system running!
• Lifecycle Stage 2: Keep the system running!

A textbook project lifecycle goes like this: Stage 1 is completed quickly (and cheaply) with a very clean transition to Stage 2, and then Stage 2 just keeps running without downtime. This is a critical concept because when you buy (or build) software, you don't get any return on investment until your company has started to rely on the system. In order to rely on software, users must expect the data to be accurate and the system to be available. Whew! Now you are ready for the psychology aspects of lifecycle.

Living through a project lifecycle is like learning to drive a car. You should expect to have some false starts, to break some rules and even to have some crashes before things smooth out. And just like teaching someone to drive, some people can handle a Stage 1 environment better than others, and vice versa.

There is a type of person who enjoys the challenges and problem solving associated with getting a system running. These people thrive on lifecycle Stage 1 activities like customizing software, finding bugs and putting out fires. They enjoy the thrill of learning something new and feel compelled to constantly change and tweak a system (they call it improving). Consequently, the idea of a one-hour downtime or losing a day of data does not really bother a classic Stage 1 person if it lead to a minor system enhancement.

On the other hand, other people seem to prefer the tuning, control, and planning activities needed to keep a system running for lifecycle Stage 2. These people get a lot of satisfaction from learning everything about the software and take pride from long stretches of system uptime. A Stage 2 person will fight to control changes the software and then carefully test and orchestrate a changeover to have minimal impact on users. Consequently, the idea of making a series of rapid configuration changes or shutting down a server to install a patch gives a Stage 2 person indigestion.

If you acknowledge these stereotypes, then you can turn them to your advantage so your implementations are more effective. The benefits are enormous because you are acknowledging that good implementations do not end when the software is installed and customized. So before you claim implementation victory you must not only win in Stage 1, you must also successfully move the project into Stage 2. This means that you may actually need two people because the person who was instrumental in getting the software running may not be your best bet to keep it that way.

I'll illustrate with my experience on a site visit to a midrange manufacturer. The manufacture had a modest one-person IT staff, and this person was its ERP guru. Let's call him Will Tinker. Unfortunately, Will was a classic Stage 1 personality; he was constantly adding and customizing the package to the point where users hardly even saw the vendor's screens even though the software had been installed for years. For example, we asked someone from accounting if she used standard or actual costing. Her response was, "I've never seen that option, I don't think it's on the screen Will wrote for us."

Will had been working for years to defeat his ERP system's underlying business logic (he had rewritten the vendor's MRP engine). I don't think that Will had planned on writing a custom ERP system on top of the one his company had purchased, it just happened. This is not surprising since his Stage 1 personality drove him to constantly solve problems and make improvements. In fact, Will was considered a company hero since his employer got the benefit of custom logic tailored to its business.

I see the situation differently. Will's employer had to live through a constant stream of changes and bugs with minimal documentation. It had no idea of the actual cost of these changes since did not have to submit invoices for his time, and support issues (like backups or documentation) waited on the back burner while Will wrote code. On top of that, the ERP software was supposed to improve the company's business processes, but Will was so eager to "improve" the software that the firm lost opportunities to re-engineer or use best practices.

If Will had been more of a Stage 2 personality, he would have been more interested in getting users to training and controlling change. He would still be an ERP guru, but his focus would be custom reports instead of custom screens. Maybe he would have figured out how to map in electronic data interchange transactions or enable to product for email. Will's extensive knowledge of the software's unmodified processes would have also helped re-engineer his company's business processes. There are almost as many ways for Will to support a system as there are ways for him to customize it.

Part of the problem was that no one could give Will much knowledgeable oversight. If Will had been a consultant instead of an employee, the company would have been much more motivated to control its expenses by watching his time and ultimately ending the project. Since it cost the company real dollars, it probably would not let him start to customize a screen without first finding out what he planned to do, how much it would cost and what benefits would result.

How can you apply this knowledge to your implementations? When you accept lifecycle psychology, you accept that success depends on people. If you want a winning implementation, you must be aware that people's personalities control the lifecycle and the lifecycle controls your outcome. Use Stage 1 people for Stage 1 work, involve your people for a Stage 2 early and orchestrate the hand off, and then manage the transition to make it happen.

I have one last point before you grab your diploma. In my experience, consultants enjoy the new challenges and problem solving associated with getting a system running (Stage 1) while corporate technology department employees tend to be more interested in stability and support (Stage 2). This personality difference extends to the expertise each type brings to an implementation. Consultants have product knowledge and start-up experiences, while technology staffs usually develop encyclopedic knowledge of maintenance tips and optimization tricks.

This leads up to an implementation irony: investing in outside consultants for Stage 1 of a project actually reduces your lifecycle cost when you factor in personality, accountability, and experience. In addition, your technology staff is freed from startup worries and can focus on learning the system and support issues very early on. After all, the smoother Stage 1 goes, the more successful the implementation and the sooner your business gets the benefit. When you fit people's personality and expertise to the right parts of your system's lifecycle, your implementation and your company reap rich rewards.

For subscription information go to mfg-erp.com

Return to Hirschfeld Consulting Home